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I. BACKGROUND 



In any emergency, the right decisions must be made 
quickly. The more information a decision-maker (manager) 
has, the better his decision is apt to be. However, the 
more information a manager must assimilate, the less quickly 
he can reach a decision. 

This problem of information assimilation for decision- 
making would become apparent if, during a national emer- 
gency, a manager was required to determine allocation of 
scarce communication resources to many competing users. The 
manager would be forced to answer questions quickly: What 
problems need to be solved? What users are out there? What 
resources remain? How can remaining resources be used by 
the remaining users most effectively to solve problems? 

A Decision Support System (DSS) can aid a manager in 
answering these kinds of questions by assimilating, 
selecting and presenting needed information in form and 
volume the manager can understand and use quickly. 

Such a DSS would allow an emergency decision-maker the 
option of considering the projected outcome of various 
possible choices through simulation models, selectively 
considering only needed information while screening out 
extraneous data and seeing, by using stored models, how 
changing circumstances alter the decisions reached. 

An emergency-scenario DSS must possess certain charac- 
teristics to be useful to an emergency manager. The system 
must be portable to accompany the emergency manager to 
disaster sites. It must contain sufficient computer memory 
to house a database and sophisticated software programs used 
to interpret the database and provide simulation and opti- 
mization modelling. The user must have exclusive use of the 
DSS. In an emergency, the manager must use an instantly 
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responsive system to enable him to receive information 
quickly. 

Present day microcomputers are very appropriate to house 
such decision support systems. Unlike main-frame computers 
or minicomputers, microcomputers are fully portable, 
requiring only a power source. With the explosive refine- 
ments in hardware production, microcomputers now have suffi- 
cient available memory to house sophisticated databases to 
store and organize information, software modelling and opti- 
mization algorithms to interpret information and complex 
graphics packages to display the interpreted data in forms 
selected by the decision-maker. 

Several examples of microcomputer use for emergency 
decision support systems exist. Three will be described 
briefly. 



A. U. S. COAST GUARD SEARCH AND RESCUE PLANNING ( SARP ) 

Part of the mission of the United States Coast Guard is 
to search for and rescue persons and craft lost at sea. To 
do this, the Coast Guard must identify the presumed position 
of the person or craft, called the "datum", and direct 
search and rescue ( SAR) teams to that position. Fixing the 
datum 1 s position on the ocean surface involves four steps 
[Ref. 1], 

1. Determine drift forces. Three types of forces can act 
on a person or craft to move them over the water s 
surface. Sea current is the permanent, large scale 
flow of the ocean waters. Wind-driven current is the 
current generated by the wind acting upon the surface 
of the water for a period of time. Leeway is the 
movement of an object through the water caused by 
local winds blowing against the exposed surface of the 
ob j ect. 

2. Determine vectors. These vectors are based on the 

three types of forces to determine datum position. 

3. Determine error margin. Any possible error margin 
must be calculated for the vector determinations made 
in step three. 

4. Determine the search radius. A search radius must be 
calculated around the datum position that will ensure, 
with a better than fifty percent probability, that the 
search target is within the search area. 
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Prior to the early 1970's, the Coast Guard performed 
manually the four steps described above. The current drift 
forces were determined by averaging wind and water speeds 
through weather forecasts. The vectors were determined 
through calculations. Error detection was not performed 
because such lengthy re-calculations consumed precious time. 
The search radius was determined through calculations and 
statistical formulas. The total time required to calculate 
the datum position and search radius manually was approxi- 
mately forty-five minutes to one hour and required a search 
planner reasonably familiar with the system. 

In the early 1970's, the Coast Guard automated the four 
steps on a time- shared main-frame computer. To use this 
system, the search planner drafted a message containing the 
time of the incident, the incident position, the desired 
datum time, two error calculation numbers obtained from the 
National SAR Manual and the type of leeway to be considered 
(obtained from a computer handbook). The message took 
approximately five minutes to draft and was sent by teletype 
to the main- frame computer. The SARP program reply, with 
the datum position and search radius, would be received by 
the search planner within twenty minutes, if no problems 
arose. If the search planner or the teletype operator typed 
errors into the message, the mainframe computer would send 
an error message back and the message would be retran- 
smitted. This caused delays of up to several hours since 
the search planner would not know his message was unusable 
until he received the computer response. The computer 
program was inaccessible when the mainframe computer was not 
operating or when the teletype circuit was broken. In this 
case, the datum position and search radius were calculated 
manually. 

In 1982, the SARP program was installed in a microcom- 
puter. The current microcomputer version of the SARP 
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program presents the search planner with a menu-driven 
display which prompts him for needed information. The 
program can calculate the datum position and search radius 
in approximately thirty minutes. The search planner works 
directly with the system, without a teletype interface and 
can verify immediately that his input is keyed in correctly. 
The system is reliable since the microcomputer is always 
accessible to the search planner. 



B. AMERICAN RED CROSS EMERGENCY MANAGER DECISION AID 

In a disaster, the Red Cross quickly and accurately 
assesses the physical severity of the disaster and the 
ability of people to cope with their losses [Ref. 2]. The 
Red Cross thus determines the level and monies which must be 
expended to alleviate the situation. To do this, the Red 
Cross performs four procedures. 

1. Predisaster Surveys. The Red Cross maintains files of 
information gathered by periodic surveys conducted by 
local Red Cross chapters. These surveys estimate the 
value of property as well as facts about insurance 
coverage. 

2. "Windshield surveys". Immediately after a disaster. 
Red Cross field teams assess and record the extent and 
nature of property damage. 

3. Determination of disaster severity. The Red Cross 

emergency managers on site use the windshield 

surveys , together with pre-disaster information, to 
determine the severity of the disaster and the appro- 
priate resources that must be brought to the disaster 
site. 

4. Case file preparation. At Red Cross emergency 

centers, emergency managers use the pre-disaster 

surveys, "windshield surveys" and claims of disaster 
victims to determine the extent of disaster victims 
needs. 

The Red Cross emergency managers must determine the 
severity of the disaster, the resources necessary and the 
fair resolution of victims' claims very quickly. They are 
required to compare data on pre-disaster conditions with 
disaster reports. They must ensure that disaster victims 
are fairly compensated, but that duplicate claims are not 
accepted. 
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When the emergency managers perform these procedures 
manually, many problems arise which can be attributed to a 
lack of two requirements, which are discussed below. 

1. Timeliness. The managers cannot respond quickly to 
victims claims if they must manually review and 
attempt to connect pre-disaster surveys, windshield 
surveys" and victims claims. 

2. Accuracy. If expedition of claims processing becomes 
paramount, survey reviews and therefore prevention of 
duplicate claims becomes harder. 

In 1979, the Red Cross tested a microcomputer-housed DSS 
in an actual field incident. The database within the DSS 
organized the information gathered by pre-disaster surveys. 
The information gathered by "windshield surveys" was entered 
into the database by simple menu-driven questionnaires. The 
emergency manager could then use DSS-driven programs to 
compare pre-disaster conditions with disaster information to 
determine disaster severity and the recovery resources 
required. 

Case workers could enter files for victims by names, 
ensuring only one claim was filed per family, and then 
verify the victims' claims by comparison of their claim with 
pre-disaster survey information. All this information was 
reliable, available quickly and much more accurate than 
information gathered by manual methods. 

C. REGIONAL EMERGENCY MEDICAL ORGANIZATION (REMO) 

This organization, located in a six-county region around 
Albany, New York, is responsible for coordination of an 
emergency medical system which provides the region with 
effective medical services in the event of any emergency 
situation. Such service includes allocating ambulances in 
situations where the need for the ambulances exceeds the 
supply. 

To allocate the ambulances, the REMO dispatcher uses a 
DSS programmed on a microcomputer. The DSS attempts to 
minimize total time victims have to wait for an ambulance as 
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well as minimize "bottlenecks" caused by over-allocation of 
any ambulance. The dispatcher users graphic map displays 
showing demand and resource locations. The DSS uses an 
optimization model algorithm to calculate the optimum ambu- 
lance use, given the resources and demand. The dispatcher 
can input different demand priorities to observe how 
different ambulance utilization and routes will change the 
optimal allocation. 

The ability to determine optimal allocation under 
different circumstances before he dispatches the ambulances 
allows the dispatcher to assign ambulances more effectively 
and thereby reduces some of the job stress, and attendant 
mistakes, he might make by manual determination of ambulance 
allocation. 

These three examples illustrate the value of a DSS to 
decision-makers in three areas critical to emergency deci- 
sions: speed, accuracy and data manipulation. The Coast 
Guard DSS provides information that leads to quick assign- 
ment of rescuers. Using their DSS, the Red Cross workers 
can approve damage claims for disaster victims with much 
greater faith in the accuracy of their data, than by manual 
methods. The REMO dispatchers can use their model algorithm 
to interpret the raw data of ambulance and passenger posi- 
tions into optimal routes, thereby eliminating data inunda- 
tion of the dispatchers. 

As has been discussed, an emergency decision manager 
faces three basic requirements in any decision he makes. 
The decision must be made quickly to avert disaster or 
alleviate an emergency. The decision must be right, since 
emergencies do not allow for multiple attempts to solve a 
problem. The decision usually must be backed by analysis of 
data, which in an emergency comes to the decision-maker 
quickly and in an unorganized fashion. A computer-driven 
decision support system can help an emergency manager 
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immensely in several ways. It can provide models of 
possible results of decisions, allowing the decision- maker 
to see the probable results of his decisions before he makes 
them. This modelling facility allows the decision-maker to 
improve the chances his decision will be accurate. The DSS 
can sort, interpret and present information to the decision- 
maker in a format he can understand. This data handling 
facility protects the decision-maker from inundation by all 
sorts of data, some of which he must know to reach a deci- 
sion and some of which is superfluous to the decision 
process. Finally, the DSS performs these functions much 
faster than possible by a human staff. 

The Decision Support Systems described in this chapter 
work because they provide decision-makers with the facili- 
ties described above. As will be seen in subsequent chap- 
ters, the FAMIS emergency manager will require the same 
types of services to perform his allocation decisions. 
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II. INTRODUCTION 



Coping with the consequences of a nuclear attack and 
dealing with the aftermath of a natural disaster such as a 
hurricane or earthquake involve different problems, 
resources and solution methods. All such disasters, 
however, require reliable communications to allow people to 
assess impact, make decisions, put appropriate responses 
into play, allocate needed resources effectively and restore 
social stability. Given this country's dependence on tele- 
communications as a quick, reliable means of communication, 
the establishment and maintenance of a reliable telecommuni- 
cations system in the advent of an emergency is vital for 
recovery from the disaster. 

In recognition of this need, the Federal Government has 
empowered the National Security Council (NSC) to develop 
policy for emergency telecommunications management in 
conjunction with the Federal Communications Commission 
(FCC). The Nationwide Emergency Telecommunications System 
(NETS) that will eventually be developed will use existing 
resources of the Public Switched Network, to provide commu- 
nications among many field recovery agents, who will oversee 
regional survival and recovery actions. 

Since the break-up of AT&T, the Public Switched Network 
(PSN) has become controlled by many private and public 
companies. This thesis will not address the issues of 
policy, authority, and management which NCS must address to 
obtain cooperation of the various private companies and 
government agencies required to establish a viable NETS. 
Since this thesis is concerned with the automation of a 
certain decision aid tool for use in the operation and 
control of the NETS system, a working, valid NETS will be 
assumed to exist. The following discussion of emergency 
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telecommunication requirements assumes the existence of NETS 
and requires cooperation among agencies. 

The PSN refers to the combination of assets established 
by private, public and government agencies which are the 
telecommunications system for the United States. These 

assets include telephone lines, nodes to connect the lines, 
teletype/digital switching facilities to direct communica- 
tion loads, satellite communications, microwave facilities 
and many other telecommunication devices [Ref. 3]. These 
assets allow a student in California to call his mother in 
Georgia, allow computers in New York to "talk" to computers 
in Hawaii and permit the Department of Defense to issue 
directives to military bases. 

In an emergency, this telecommunications system would 
form the ideal media for emergency communications because: 

1. it is already in place, 

2. it can access the entire country, and 

3. it is highly redundant, which means that many 
different communication routes exist between the same 
two points. 

Given that NCS is empowered to manage this system in an 
emergency, questions regarding the policy and method of 
allocating the resources, i. e. the available telephone 
lines, of this system must be addressed. In an emergency, 
it can be anticipated that many more people will want to use 
available telecommunication facilities than are available. 
The telephone companies handle such an overload on Mother's 
Day and Christmas by queueing calls. That is, the caller 
gets a busy signal, or a "sorry, we're busy" message, until 
lines are available. 

Such blind queueing will not be a workable solution to 
overload of emergency telecommunications lines because of 
possible: 

1. low priority use. Such arbitrary gueueing might 
prevent a caller with a more valuable function, such 
as delivery of hospital supplies, from making a call, 
while allowing the college student, who called first, 
to see if his mother is all right. 
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2. insufficient use. Unless controlled, lines might be 
in heavy demand for certain periods and in no demand 
during other periods. Callers who could have 
completed necessary calls at certain times would be 
unable to complete calls at other times. 

The problem of blind queueing would be aggravated by 
loss of lines. Natural or nuclear disasters could destroy 
part of the telecommunications system, which is mostly 
comprised of lines stationed above ground. 

An alternative to blind queueing is active allocation by 
NCS managers of resources (telecommunication lines) to 
recovery agants. As was shown in the REMO example in the 
previous chapter, such allocation decisions can be made more 
effectively by a manager with automated decision aids. In 
recognition of this fact, NCS is currently developing the 
Fly-Away Management Information System (FAMIS). 

A. FLY-AWAY MANAGEMENT INFORMATION SYSTEM (FAMIS) 

FAMIS currently exists in prototype form only. 
Installed on a microcomputer, it is a file-drawer system in 
that it is used solely for information retrieval. The 
following information is currently available to the FAMIS 
user. 

1. A list of primary and secondary points of contact for 
various government and private agencies. 

2. Instructions for activating emergency procedures. 

3. Graphic map depictions of the NETS. 

4. A damage model which will allow the user to superim- 
pose simulated damage on the NETS, to determine 
projected remaining resources. 

5. A word processor, currently Wordstar. 

This thesis will discuss the possible characterization 
of a Decision Support System, which is a needed sixth 
feature of the FAMIS system. In determining the character- 
istics of the FAMIS DSS, questions and objectives which the 
emergency manager must address through the DSS will be exam- 
ined in Chapter III. Information needed to answer these 
questions will be identified in Chapter IV. The necessary 
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computer literacy of the emergency manager will be discussed 
in Chapter V. A possible adjudication algorithm will be 
analyzed in Chapter VI. Finally, the proposed DSS itself 
will be presented in Chapter VII. 



19 



III. DSS DESIGN REQUIREMENTS 



This chapter will explore the objectives the FAMIS 
manager will achieve through utilization of a DSS. Since 
these objectives involve decisions made by the FAMIS 
manager, the decision process itself will be briefly 
discussed. Design requirements for a DSS will be described. 

A. DECISIONS AND THE DECISION-MAKING PROCESS 

Decisions can be defined as the end-products of 
information-processing. Any information-processing system 
that yields the finished product, i. e. , the decision, can 
therefore be considered to be a decision-making system. For 
purposes of our example, the FAMIS manager will be consid- 
ered a decision-making system. 

A structured decision, also called a programmable deci- 
sion, consists of three steps: 

1. defining the problem, 

2. designing choices, and 

3. choosing the best choice. 

If any of these steps cannot be described to a computer, 
the decision is considered unstructured. That is, human 
qualities of experience, association and intuition are 
necessary to reach a decision; the decision cannot be 
reached logically by a computer alone. 

A DSS can aid a human manager in such decision-making in 
that it can answer structured questions posed by the manager 
that aid him in solving the unstructured problem. A simple 
example of such a decision aid is a pocket calculator. By 
itself, the calculator cannot suggest answers to engineering 
questions, but it can solve mathematical equations chosen by 
a construction engineer which allow the engineer to then 
decide where a new dam should be built. 
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A more complex analogy can be drawn between a DSS and a 
human staff. When a manager with a staff faces a problem, 
he requires his staff to use available statistics, histor- 
ical data or other information to produce answers to ques- 
tions the manager then uses to help him decide. The answers 
such a manager seeks from his staff are not the direct 
answers to the problem. Rather, the manager's questions to 
his staff usually take the form of: 

1. request for retrieval of information. Such informa- 
tion can involve statistical analysis of raw data or 
other such grouping, and/or 

2. request for modelling information. Such requests 

usually take the form of ad hoc questions and involve 
projection of possible outcomes using historical data, 
optimization algorithms and data comparison. 

The manager uses these answers to acquire some indica- 
tion of consequences of various decisions. He can therefore 
make a decision with more authority. Such staff support 
differs from simple data retrieval because the staff is 
expected to interpret the raw data and present to the 
manager only that information, in a determined form, which 
will aid the manager in his decision process. 

The staff therefore serves two functions for the 
manager: 

1. providing the manager with information necessary for 
his decision, and 

2. screening from the manager extraneous data, the diges- 
tion of which would interfere with his 

decision-making. 

A truly effective staff can call upon enough varied analysis 
tools to provide answers to the manager's varied questions. 

A computer-generated DSS should fill the same require- 
ments as the staff for the manager. Using a DSS, a manager 
should be able to manipulate and selectively use information 
to determine answers which will enable him to make intelli- 
gent decisions for unstructured problems typical of the real 
world. 
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B. DSS DESIGN REQUIREMENTS 
1. Design Criteria 



Generally, decision support systems reflect four 
design criteria. 

a. Representations 

This means the use of CRT tubes in conjunction 
with software programs which will present reports, charts, 
geometric representations, etc. Such representations must 
be constructed in a form that is understandable to the 
decision-maker. 

b. Support 

Support of intelligence, design and choice 
activities. This includes operations like comparing current 
status with goals or standards, exception reporting and 
preliminary calculations. 

c. Memory Aids 

This includes English-like Data Base Management 
Systems (DBMS) which allow flexible, interactive access to 
data. The decision-maker requests information from the DBMS 
in English. The DBMS then constructs the software programs 
necessary to retrieve and organize the information. 

d. Decision Maker Control 

This means man-machine interaction, online and 
in real-time without the intermediary of programmers. Such 
immediate interaction between the DSS and the decision-maker 
is vital for three reasons. First, such interaction allows 
the decision-maker to see his input, assuring it is entered 
error-free. Second, an interactive DSS allows a decision- 
maker to ferret out specific information from a large amount 
of unassociated data quickly. Third, the decision-maker can 
observe answers to his questions immediately. Such imme- 
diate response is especially vital in an emergency, where 
the decision-maker must have projected result information 
quickly. 
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2. Requirements 

To support these criteria, a DSS must fulfill the 
following requirements. 

a. Data Management Capability 

A data base management system (DBMS) must exist 
as a software interface between the decision-maker and his 
database. A database is a collection of data, also called 
information, which is organized logically into a system of 
some sort. The DBMS software programs accept requests from 
the decision-maker, in English, for information. The DBMS 
then retrieves the information, which may be stored logic- 
ally in many disparate physical locations in computer 
memory. The DBMS then organizes, arranges and presents the 
information to the decision-maker, in a form specified by 
the decision-maker. For instance, a manager might request a 
list of all telephone users who require a dedicated phone 
line, and he may wish to see this information in a table, 
arranged in ascending order by last name. A good DBMS will 
take the English request and utilize the necessary software, 
internal to itself, to produce the table. At the manager's 
request, the DBMS can present the same information arranged 
by location of the user. 

b. Analytical Capability 

As mentioned previously, a DSS must be able to 
manipulate data, as well as present it. Many kinds of anal- 
ysis tools are used by decision support systems and these 
tools vary in complexity, depending on the depth of analysis 
required and the breadth of data to be considered. A 

partial list of such analysis tools could include [Ref. 4], 

(1) Data Analysis . In data analysis, 

historical data is subjected to statistical analysis and 
other projection formulae to determine trends, to project 
future outcomes and to determine present status. Many 
businesses use such analysis to predict sales trends, to 



23 



help compile five-year budget plans and other activities 
which require analysis of historical data. A FAMIS manager 
might use this tool to determine present capacity of lines 
or to compare priorities of competing users. 

(2) Simulation . In simulation models, 
projection of outcome is based on algorithms which involve 
data. Such models are different from data analysis. In 
data analysis, the historical data and all factors which act 
on the data, i. e. interest rates, are known. In simulation 
modelling, some of the parameters which act on the data are 
unknown or assumed. A factor of uncertainty is thereby 
introduced. Representational models are particularly 
valuable when answering ad hoc kinds of questions, where 
some circumstances must be assumed to project an answer. 
The FAMIS manager could use a tool of this type to simulate 
reallocation of resources to accommodate a coast- to-coast 
line connection for two high-priority users. 

(3) Optimization Models . These models 
describe situations mathematically as complicated puzzles 
whose solution is maximization or minimization of a 
particular goal. Optimal use of FAMIS resources, subject to 
certain constraints such as minimization of nodes involved, 
might be a potential problem which a DSS would employ an 
optimization model to solve. 

(4) Suggestion Models . These models are more 
structured than optimization models and whose output is 
pretty much the answer to the decision-maker's problem. 
Such models are called expert systems and, while applicable 
to many areas, are inappropriate for application in the 
FAMIS system. Suggestion models are designed to suggest 
actions based on a pre-determined set of criteria or 
conditions. If these criteria change, such as changing the 
condition mode of the FAMIS system from survival to 
recovery, the suggestion model must be altered to produce 
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new suggestions based on the changed goal of recovery. It 
is considered more feasible in the FAMIS system to allow the 
manager to assume this role, supported by optimization, 
simulation and data analysis models as described above. 

c. Transportability 

It is unrealistic to presuppose that an emer- 
gency decision-maker will be able to remain at a particular 
location during an emergency. Available communications 
resources, facilities and other concerns might force such a 
manager to be mobile. A DSS used to support such a manager 
must be portable. The potential problems of interfacing 
with a stationary mainframe computer were illustrated in the 
Coast Guard SARP program example. 

d. Reliability 

DSS reliability will be of two types: reli- 
ability of the interface between the manager and the system, 
and reliability of the information passed between the 
manager and the DSS. Reliability of the interface, that is 
the percentage of time the manager can use the DSS, will be 
best served by having the decision-maker as the sole user of 
the DSS. Reliability of the information exchanged can be 
best assured by an interactive system, where the manager can 
instantly check that he enters the proper data and can 
instantly see the actual response from the DSS display. 

e. Flexibility 

It is impossible to determine in advance all 
questions a manager will be required to ask a DSS to accumu- 
late enough pertinent information to make a decision. 
Therefore, a DSS must possess the flexibility in its soft- 
ware to accept new questions formulated by the manager. For 
instance, a menu-driven DSS which will only answer three 
pre-determined optimization questions will be of limited use 
if new circumstances arise. Such flexibility could possibly 
be built into a DSS by: 

a) generalization of the model/analysis programs 
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b) incorporation of a model-building ability within the 
DSS. Such a model-building program would construct 
new algorithms for models as the manager requests new 
analysis approaches. 

f. Maintainability 

Maintainability, particularly of the database, 
is vital. A DSS used by the FAMIS system will be only as 
useful as its data is current and accurate. Optimization of 
user use of communication lines by priority will be impos- 
sible if some of the users no longer exist or if the lines 
specified have been changed prior to the emergency. 

As discussed above, these requirements would be 
essential in a DSS associated with the FAMIS system. The 
requirements of portability and reliability would be best 
satisfied if the DSS resided in a microcomputer. The data- 
base on a microcomputer could be updated periodically by 
floppy disk or by connection through a modem, prior to emer- 
gency conditions, to ensure information is current. Most 
analytical tools, display packages and database management 
systems can operate in a modern microcomputer. 

The actual components of a generic DSS, 

including design specification, program description, data- 
base types and hardware/software implementation will not be 
discussed in this thesis. The FAMIS system will serve as 
determinant of questions the manager and the DSS must 
address, as well as for description of data formats used for 
application of the DSS. These issues are considered in the 
following chapter. 
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IV. QUESTIONS ADDRESSED BY THE FAMIS MANAGER AND THE DSS 



Within the FAMIS scenario, the manager must decide on 
the allocation of remaining scarce telecommunication 
resources to a competing set of qualified recovery agents 
who need those assets to solve specific problems associated 
with the emergency. As described in Chapter II, all avail- 
able private and public telecommunications links would be 
combined to form an emergency communication network in the 
advent of a disaster. The Public Switched Network (PSN), 
which is the major telephone communications system in the 
country, is a vast complex of local offices, trunks and 
switching nodes. Given that it is feasible to reconstitute 
an emergency network from the surviving nodes and links, if 
the remaining available resources exceed the requirements of 
the users, the manager's allocation decision is uncompli- 
cated and does not require the aid of a DSS. 

However, if the recovery agents' requirements exceed 
available remaining communication resources, -as is expected 
in the FAMIS system, then the manager must answer several 
questions associated with resource allocation. 

These questions can be grouped into four broad 
categories: 

1. What problems associated with the emergency need to be 
solved? 

2. What recovery agents are out there to manage the 
required resources necessary to help solve the 
problems? 

3. What communication resources remain? 

4. What communication resources are needed to help which 
agents mobilize remaining resources to help solve 
emergency problems? 

This chapter will discuss these four categories. The 
categories themselves will be discussed and questions 
addressed by the DSS will be identified within applicable 
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categories. These questions will be examined and a neces- 
sary flow of information will be established which will be 
shown to culminate in resolution of allocation questions. 

A. WHAT PROBLEMS NEED TO BE SOLVED? 

In a national or regional disaster, the problems an 
emergency manager faces can be expressed in terms of mobili- 
zation. Mobilization is the process of marshalling 
resources to support a response to an emergency. [ Ref. 5] 
Resources can include food, medical supplies, troops, 
building supplies and whatever else is needed to survive and 
recover from a disaster. Several categories of mobilization 
exist, dependent on the types of resources being mobilized 
and/or the application of these resources. 

• Military mobilization - deployment of manpower, weapons 
and tactical information. 

• Industrial mobilization - marshalling the 

manufacturers/producers to supply goods and services. 

• Economic mobilization - marshalling money and credit to 
fund the mobilization effort. 

• Human Resources mobilization - marshalling people to 
perform needed work toward survival and recovery. 

• Infrastructure mobilization - marshalling such systems 
as transportation, energy, communications, construction 
and agriculture to support survival and recovery 
efforts. 

• Civil. Defense mobilization - marshalling forces to 
provide protection and recovery for people and industry 
from nuclear attack. 

• Governmental mobilization - marshalling resources of 
local, state and federal governments to respond to and 
recover from the disaster/emergency. 

In an emergency or disaster, regional recovery agents 
will manage these mobilization steps within their own 
geographic areas. The FAMIS system exists to allocate 
scarce remaining telecommunications resources to these 
recovery agents to enable the agents to direct mobilization. 

Thus, the crucial first problem the FAMIS manager must 
address concerns identifying mobilization requirements. The 
category of mobilization needed will depend on the type of 
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emergency/disaster. Logically, this information will come 
to the FAMIS manager from regional recovery agents or from 
other sources who have current information about the type 
and scope of the emergency or disaster. Since the FAMIS 
manager needs this information before he can allocate NETS 
resources, it is logical to assume that this information 
must reach the manager via a more dependable communication 
medium than the telephone. A high-frequency radio network 
is a viable possible communication medium for transmission 
of this initial information. Once the NETS is established, 
the FAMIS manager could also receive mobilization require- 
ment updates from recovery agents via NETS calls. 

Once the mobilization problems have been identified, the 
FAMIS manager can begin to solve these problems by deter- 
mining answers to the questions in the remaining three 
categories listed in the introduction to this chapter and 
discussed below. 

B. WHAT RECOVERY AGENTS ARE OUT THERE TO MANAGE THE 

REQUIRED RESOURCES? 

To answer this question, the FAMIS manager will elicit 
information from the FAMIS DSS, as well as real-time infor- 
mation from his high-frequency radio network and/or NETS 
updates. 

1. What is the current mode ? 

Allocation of communications resources will be 
dependent on the user's importance relative to the current 
mode or goal. If the emergency is in a survival mode, then 
recovery agents whose functions involve procurement and 
distribution of food, hospital provisions and other imme- 
diate needs might receive highest priority to use communica- 
tion resources. If the emergency mode has changed to 
recovery, then recovery agents essential to re-establishment 
of non-essential services might receive higher allocation 
priority. The need to establish an emergency government 
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might require priority use of resources by users who were 
unimportant for survival mode operations. The FAMIS manager 
will determine the current mode via high-frequency radio 
network and/or NETS updates from recovery agents or other 
field officials. 

2. What recovery agents are needed to mobilize 
resources for the current mode ? 

The DSS will obtain the number and type of remaining 
recovery agents from updates from the FAMIS manager or 
through disaster modelling. The communication requirements 
of the recovery agents will have been determined before the 
disaster took place and will be part of the FAMIS database. 

The following information has been collected for 
each recovery agent: 

1. FACILITY TYPE/IDENTIFICATION. This includes the type 
of facility ( e. g. , C2 facility, field office, emer- 
gency operations center, warehouse) and any identi- 
fying name or number that be helpful in distinguishing 
it from other facilities. These facilities are those 
that are essential in the performance of the listed 
functions. 

2. FUNCTION PERFORMED. This includes the number of func- 
tion s) that would take place at the facility. 

3. LOCATION. The name of the nearest city or town and 
state. 

4. LONGITUDE/LATITUDE. This information would fix the 
facility on a graphics map. 

5. NUMBER OF PEOPLE REQUIRING COMMUNICATIONS AT THE 
FACILITY LOCATION. This would identify people who 
would perform essential functions. 

6. TYPE OF VOICE COMMUNICATIONS NEEDED. Types include 
switched, which refers to standard switched telephone 
requirements including data needs that can be met 
using a dial-up line or a modem, and private point-to- 

E oint, which refers to private line voice systems 

etween specified locations, used for security trans- 
missions. For each communications requirement, the 
number of lines needed, the average number of hours 
per day the telephone would be in use to provide the 
essential function and security requirements would be 
listed. 

7. DEDICATED DATA REQUIREMENTS. This refers to the 
number of dedicated, non dial-up data communications 
circuits needed, plus any security requirements for 
these lines. 

8. OTHER SPECIAL NEEDS. 

9. PRIORITY. This refers to the relative priority of the 
locations listed. Notice that different priorities 
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can apply to a user under different allocation goals. 
The DSS might be required to assign several priorities 
to each user, and select the priority appropriate to 
the allocation goal of survival, recovery or estab- 
lishment of government. 

The DSS would retrieve these facts, encoded in the 
database for each recovery agent, to determine their mobili- 
zation task, communication requirements and, under the 
current condition mode, priorities to use remaining communi- 
cation resources. 

3. Of these qualified recovery agents . how many still 

exist ? 

It can be assumed that, in any disaster, a subset of 
all recovery agents will be destroyed, incapacitated or 
otherwise rendered ineffective. To determine accurately how 
many recovery agents actually remain, the FAMIS manager will 
be required to augment and modify the historical recovery 
agent data he will receive from the FAMIS DSS. His high- 
frequency radio link or contacts he can make via the NETS 
are means of providing this information. An additional 
source for projection of recovery agent losses could be 
input from the FAMIS disaster model, which would indicate 
locations affected by disaster. Recovery agents in these 
locations could be assumed destroyed for communication allo- 
cation purposes, subject to confirmation by high-frequency 
radio or NETS link. The FAMIS manager must then input the 
corrected recovery agent information to the DSS database to 
maintain accuracy. Such accuracy regarding recovery agent 
information will become vital when the FAMIS DSS is asked to 
optimize allocation of communication resources. 

At this point, the FAMIS manager will have identi- 
fied the mobilization problems caused by the disaster and he 
will have identified, through DSS retrieval of information 
coupled with high-frequency radio updates, the qualified 
recovery agents who currently exist to solve the mobiliza- 
tion problems. 
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C. WHAT COMMUNICATION RESOURCES REMAIN? 



The FAMIS manager must next determine the status of the 
existing communication network, over which he will allocate 
recovery agent communication use. To determine current 
network . status , the FAMIS manager will retrieve answers to 
the following questions from the FAMIS DSS. 

1. What is the normal network schema ? 

The DSS will use database files to determine the 
normal network of communication lines and nodes. 

2. What resources ( communication lines . nodes ) remain ? 

Using a disaster model, plus casualty information 

fed in by the FAMIS manager, the DSS will then project the 
percentage and locality of lost communications to determine 
what resources remain. 

3. Do these nodes connect local lv/nationallv ? 

The DSS must then use historical database informa- 
tion to determine if surviving nodes connect to form a 
local, regional or national network. 

4. I_s there connectivity ? 

Once this information is determined, the DSS can 
project the degree of connectivity, together -with a graphic 
map display showing the route(s) of connectivity, to the 
FAMIS manager. The manager can alter this graphic display 
to reflect new connectivity information by asking the FAMIS 
DSS to compare original connectivity data with updates 
received via the high-frequency radio network or NETS. 
Also, as discussed in Chapter II, the presence and degree of 
connectivity must be updated as further damage is sustained 
by the network. The DSS could automatically check the 
status of the networks periodically or at the update request 
of the FAMIS manager. 

5. What is the capacity and throughout of remaining 

lines ? 

The capacity and throughput of communication lines 
are important when considering the lines' ability to 
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accommodate a set of users. Once the existence of remaining 
communications lines has been established, the DSS can 
retrieve their capacity and throughput figures from the 
database. The FAMIS manager would update these figures if 
so indicated by recovery agent feedback. 

6. What degree of reliability of remaining oaths 

exi sts ? 

The reliability of remaining paths will be deter- 
mined by the disaster model projection of damage, plus input 
to the manager from recovery agents who are utilizing the 
particular path. 

7. How survivable are the remaining oaths ? 

Survivability of the particular path will depend on 

projected future damage, plus historical data about the 
path. For instance, if the path is established via satel- 
lite, then the type of damage, i.e. earthquake, will deter- 
mine if the satellite, and therefore the communication path, 
will survive. 

By using the DSS capabilities of data retrieval and 
comparative analysis, the FAMIS manager will now know the 
current status of the emergency communication network. 
Using that information, plus identification of the mobiliza- 
tion problems and available recovery agents to solve those 
problems, the FAMIS manager can now address the fourth 
category of questions. 

D. ALLOCATION DETERMINATION 

What communication resources are needed to help which 
agents use emergency resources to help solve problems? 

Applying an adjudication algorithm to the information 
discussed in the three previous sections, a DSS can deter- 
mine optimum allocation of existing communication resources 
in a number of ways. This section will explore some of the 
possible ways in which allocation configurations can be 
made. 
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1 . 



I s there alternate routing ? ( Do remaina lines 
connect m more than one wav ? ) 

Given that any node will connect more than two 
lines, the possibility exists that connections between any 
two points (recovery agents) can be accomplished via more 
than one route. The DSS must establish the existence of 
alternate routing because such alternatives may affect the 
manner of allocation, as well as establish the potential 
scope of the network. The DSS could use an optimization 
algorithm applied to existing lines to identify all possible 
paths connecting all points (recovery agents). 

2. How can number of users on the system be maximized ? 
Two allocation issues become apparent in the FAMIS 

example: user priority and utilization time. The DSS will 

retrieve the current allocation goal from the manager. This 
goal will determine which type of priority will be associ- 
ated with NETS users. 

3. How can percent of time paths are utilized be 
maximized ? 

The DSS must also consider time constraints. For 
example, a higher-priority user who requires ten hours use 
per day might represent less effective use 'of the system 
than four lower-priority users who all together require only 
four hours use time per day. 

4. How can priority use on the system be maximized ? 
Given the dual allocation constraints of priority 

and time, the DSS will probably provide the manager with 
possible resource allocation based on priority and time. 
The DSS will retrieve time requirements and priority infor- 
mation for recovery agents from its database and project 
combinations of recovery agent use to optimize priority use 
or percent of time the NETS is used. 

5. How can the most reliable network between long 
distances be established ? 

The manager could then invoke further ad hoc ques- 
tions to observe the results of further tradeoffs. It is 
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important that the manager, instead of the DSS, effect these 
tradeoff questions to arrive at a compromise allocation. 
The manager, not the DSS, is the decision-maker and he must 
be able to consider the projected results of many options 
before arriving at, in his judgement, the best decision. 

6. I_s congestion possible ? 

Congestion of traffic flow over the network is a 
consideration the DSS must address in allocating communica- 
tion resources. Congestion can occur when communication 
lines into a node contain more "traffic" than the node can 
direct on to other lines. Such congestion could easily take 
place if the DSS concerns itself solely with maximization of 
the number of users of the FAMIS system, without considering 
even distribution of that user load over available nodes. 
Depending on the geographic concentration of users, some 
nodes of the system might be overloaded while others are 
hardly used, unless distribution of the user load is 
considered. 

7. I_f possible , how can congestion be resolved ? 

The DSS must have an analysis tool that will examine 
projected allocations, compare recovery agent requirements 
with line throughput and determine the possibility of 
congestion. Should congestion pass a critical probability 
point, the DSS must notify the FAMIS manager and propose 
alternate allocations to ease the congestion. Given the 
establishment of all alternate routing described above, the 
DSS could reallocate communication line use using an opti- 
mization algorithm, subject to constraints against using 
congested routes. 

Once the FAMIS manager has obtained answers to the 
questions described above, he can provide solutions to the 
mobilization problems identified. Circumstances can change 
quickly in an emergency, however, and the FAMIS manager must 
be able to obtain new answers to any and all these questions 
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if conditions change. The following questions fall into one 
of the four categories of questions discussed above, but 
they are mentioned here becuase they will be prompted by 
changes in the emergency environment. 

8. - When do conditions change sufficiently to warrant 

real location ? 

Questions which might be addressed to determine 
condition changes include: 

• Is the condition mode different? (survival, recovery, 
etc. ) 

• Have resources changed? 

• Have users changed? 

Allocation priorities might change as the allocation goals 
change, as further damage to the network results in fewer 
available communication resources or even as recovery agents 
complete their calls and no longer need the communications 
resource. The DSS would have to recognize a valid condi- 
tion of change and then examine qualified recovery agents to 
determine if their level of use priority changes. If so, 
new optimization algorithms might be required. 

Additionally, the manager might decide to ask for 
the outcome of different methods of allocation, for which 
the DSS has no programmed algorithm. In these cases, the 
DSS might be required to have the capability to build algo- 
rithms to suit such one-of-a-kind questions. 

By answering the categories of questions discussed 
in this chapter, the FAMIS manager can meet his objective of 
effecting mobilization of resources by recovery agents 
through allocation of communication resources to these 
recovery agents. The questions discussed in this chapter 
are representative of the types of questions for which data 
must be amassed and for which modelling programs and other 
analysis programs must be prepared. 
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V. THE FAMIS DATABASES 



The previous chapter presented questions the FAMIS 
manager and the DSS must address. This chapter will discuss 
possible database types and update methods. 

Data can be defined as facts, which are combined to 
provide information about something. Much of the data the 
FAMIS system will use has already been defined. Recovery 
agent information required might include: 

• location (latitude and longitude) 

• telephone number 

• type of user (his function) 

• priority of user (may be several entries, based on 
different condition modes) 

• type of resource required 

• duration of resource requirement 

• name or code of user 

Resource Information might include: 

• location (latitude and longitude) 

• category of resource ( telephone line, microwave, 
satellite relay) 

• type of resource ( full-duplex, private, switched, 
secure, etc. ) 

Other information might be needed, depending on the 
types of decisions the FAMIS manager has to make. 

Data arranged in an organized form is called a database. 
A card file can be a database, as can a printed list of 
names or facts stored in the human brain. For purposes of 
this thesis, a database will be defined as data arranged in 
a logical form and stored in a computer memory. Two 
distinct databases for use with the FAMIS DSS can be 
discerned from the data required. One of these databases 
will contain recovery agent information and one will contain 
communication resource information. Other FAMIS database 
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groups may be identifed later, but the following discussion 
of database types and update procedures will apply to those 
databases as well as to the two databases identified. 

The type of database is determined by its data model, 
which can be defined as the philosophy of relations and 
attributes of relations between data in the database. Many 
types of databases exist and four types will be identified 
and compared to determine a suitable database type for FAMIS 
application. 

A. HIERARCHICAL DATABASE 

A hierarchical database can be described as one in which 
all the data is arranged by following one logical rule. In 
a computer, a hierarchical database is arranged so that each 
bit of data has a logical pointer which points to another 
piece of data. The telephone directory, which lists all 
information alphabetically by the last name of the indi- 
vidual or organization, is an example of a hierarchical 
database system. Such a database is useful only if the data 
requested, i. e. , an address, can be tied to a last name. 
Using the telephone directory, it is impossible to ask for 
"John' s address" or to ask "Who lives at 35 Fremont 
Street?". Such questions cannot be answered because the 
telephone directory is not designed to allow retrieval of 
information by any other means than by last name. The last 
name is the "key" which unlocks the information in this 
hierarchical database. 

Clearly, such a rigid database arrangement will be 
insufficient to meet the information needs of the FAMIS 
system. For example, to answer the question of what 
resources remain, the DSS must identify resources using 
their location key. The location can then be compared with 
the disaster model results to determine which communication 
lines remain. To allocate these resources, the manager may 
wish to know how many lines of a certain type exist between 
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two points, such as secure lines, which can handle the calls 
of a certain user. To obtain that information, the DSS must 
identify resources by their type key. By considering other 
questions the DSS must use resource information to handle, 
it can be seen that the DSS must be able to access the data 
in a database using many different keys, grouping the data 
in many different ways to obtain the information needed by 
the FAMIS manager. This requirement eliminates a simple 
hierarchical database as unsuitable for FAMIS application. 

A hierarchical database could be built in a way that 
allows access of data by many different keys by producing 
separate lists of the same data grouped differently. To 
continue the telephone directory analogy, the directory 
would contain entries for each person listed by last name in 
one section, by first name in a second section, by address 
in a third section and so on. The obvious result of such 
redundancy would be a very large telephone directory. If 
FAMIS data is organized this way, much more computer memory 
storage will be necessary to contain all the redundant data. 
Retrieval of that data will be slow since most computers 
retrieve information using some form of a sequential search. 
To illustrate sequential search, we continue with our 
analogy. A person using sequential search would look first 
through the last name and first name sections and then the 
address section to determine who lives at 75 Rock Plaza, if 
the data is organized in that order. Such a search will 
waste a great deal of time looking through the two unneeded 
sections which preceed the address section. 

B. RELATIONAL DATABASE 

Such storage space and retrieval problems can be 
relieved considerably by use of a second type of database 
called relational database. A relational database can be 
described as one in which all data is stored physically only 
once, but can be accessed logically many different ways. 



39 



Such access can be accomplished because indexes are created 
within the relational DBMS which relate the bits of data in 
several ways. A relational database telephone directory 
would list each person only once, but would have indexes 
associated with each name which would logically 
re-categorize that person by last name, first name, address 
or by other characteristics. In FAMIS, a relational data- 
base would allow the DSS to retrieve information regarding 
remaining resources grouped in many different logical 
categories. This flexibility in data retrieval would allow 
the FAMIS DSS to answer ad hoc questions which had not been 
previously identified. 

A disadvantage of a relational database system is the 
direct tradeoff between data access speed and the amount of 
memory storage necessary. A relational database increases 
access speed to data by creating more indexes to group the 
data in more numerous logical ways. The increased number of 
indexes take up more memory space. However, the decreasing 
costs for memory storage hardware and the increasing 
capacity of microcomputers to house thirty and even forty- 
megabyte hard disks render this disadvantage unimportant for 
purposes of FAMIS application. 

C. NETWORK TYPE DATABASE 

Unlike hierarchical or relational databases, which use 
one-to-one and one-to-many data relationships, a network 
database type uses many-to-many data relationships. A 
network database defines sets which contain rules for asso- 
ciation of relationships between logical groups of data. 
Such a database type is effective for retrieving large 
amounts of data, but is inappropriate for answering ad hoc 
queries since this involves redefining data relationships. 
Such redefinition is more difficult when the relationships 
are defined by sets. A network database system, such as 
CODASYL, would be inappropriate for FAMIS due to this 
shortcoming. 
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D. FUNCTIONAL TYPE DATABASE (ENTITY RELATIONSHIP) 

An entity relationship database describes data as enti- 
ties and extracts information by assigning functions to 
these entities to establish relationships. Purported to 
most closely resemble human thought association methods, 
entity relationship type databases are still in pre- 
production phases and are therefore not suitable for consid- 
eration with FAMIS. 

Once the decision of which type of database FAMIS will 
use has been made, user data, resource data and other data 
will be entered into the database to incorporate necessary 
keys into the data. At that time, the issue of data design 
must be addressed. Data design refers to the structure of 
the data. Use of the existing FAMIS data design would prob- 
ably be preferable to use of a new data design because data 
already exists in the FAMIS format and because a new data 
design might not be useable with other FAMIS programs, such 
as the disaster model. 

Updating the database will be critical to successful use 
of the FAMIS system. Any DSS is only as good as the data it 
uses. If the FAMIS manager allocates resources to users who 
no longer work in their designated functions, the system 
will not work effectively. However, data integrity must be 
maintained to ensure updates of information in the database 
do not remove or alter information which will be needed at a 
future time. To preserve data integrity, it is recommended 
that the FAMIS DSS maintain two sets of databases. One set, 
consisting of recovery agent and communication resource 
information, would reflect pre-disaster information and 
would not be updated. This database would be reserved as 
the starting point for initial FAMIS calculations and as a 
reference point. At the beginning of the FAMIS DSS exer- 
cise, a second set of databases would be duplicated from the 
master set. This second set could then be updated to 
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reflect current information, while leaving the master data- 
base set unchanged. 

An example will illustrate the wisdom of maintaining two 
database sets. Suppose a region is reported destroyed. The 
FAMIS manager would update the databases to reflect the 
destruction of recovery agents and/or communication 
resources. If subsequent reports refuted the original 
report of destruction, the FAMIS manager could recall the 
original data to correct the updated database if he had an 
original master database as a reference. Without the orig- 
inal database, the FAMIS manager would have no certain way 
to reconstruct the existing communication resources. 
Updating the database of the FAMIS DSS will be harder on a 
microcomputer than on a mainframe computer because the 
microcomputer is portable and therefore not always readily 
accessible. The Red Cross handles such an access problem by 
updating database information on a periodic basis before 
disaster strikes. Such a procedure is recommended for the 
FAMIS system for two reasons. 

First, by knowing when updates will occur, the FAMIS 
manager will know how current his database 'information is 
and when he can expect the next update. 

Second, these updates, which would originate with FAMIS 
geographic area field representatives, present an excellent 
method of maintaining contact between the field representa- 
tives and the FAMIS manager. Such contact ensures the 
viability of the data received by the FAMIS manager about 
the current status of resources and users. Such contact 
also ensures the FAMIS manager knows who and where his field 
representatives are, so he can pass policy and other deci- 
sions down to them. 

The updates could be done via telephone modem hookup or 
by floppy disks mailed to updating locations. Each method 
has advantages. The modem method allows instantaneous 
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update of the database, without the time lag of mail 
service. The floppy disk method does not require the FAMIS 
manager and field representatives to be connected to the 
same network at the same time. 

The • data included in the FAMIS DSS database will be 
determined by the types of questions the DSS must address. 
Most of this information has already been identified by 
FAMIS developers, although provision must be made for inclu- 
sion of other data which is determined to be germaine to 
FAMIS use. 

A relational database, governed by a DBMS, will effec- 
tively accommodate the FAMIS data and associated indexes as 
well as provide methods to incorporate new data into the 
existing database. 

Updates of the data will be imperative. To be effec- 
tive, these updates must be frequent enough to ensure the 
FAMIS database reflects current information. The necessary 
frequency of such updates will depend on how often the data 
changes. The updates should be performed following a 
regular schedule. Such regularity promotes maintenance of 
current data, since the FAMIS manager will know when to 
expect an update and therefore will know if he has missed 
one. 

This thesis will not attempt to specify all types of 
data needed by the FAMIS DSS. As the FAMIS project develops 
and its scope of responsibility is finalized, the amount and 
type of data will be identifiable. This chapter has 
attempted to provide possible arrangement of that data in a 
database and suggested manipulation of the data by a Data 
Base Management System. 
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VI. THE ADJUDICATION ALGORITHM 



This chapter will present a possible adjudication algo- 
rithm to be used to resolve claims made by recovery agents 
for scarce communication resources. Switching facilities of 
the Public Switched Network will be briefly described to 
provide background for the algorithm. A possible claim 
problem will be isolated and discussed. The possible algo- 
rithm process will be presented and the DSS process involved 
will be discussed. 

A. REDUNDANCY IN THE PUBLIC SWITCHED NETWORK 

The current Public Switched Network (PSN) is comprised 
of switches, nodes, trunks and other telecommunications 
equipment which serve to connect the system. Many redundant 
paths between any two points exist in the PSN. This redun- 
dancy was built into the PSN to provide faster, more reli- 
able telephone service. Calls can be rerouted along 
alternate routes if congestion exists on a primary path. 

In an emergency or disaster, the built-in redundancy of 
the PSN will serve two purposes. Almost certainly, communi- 
cation resources will be in heavy demand during an emergency 
and congestion will exist on certain paths. Additionally, 
the emergency or disaster might destroy some of the communi- 
cation paths. Redundancy of paths will be used to relieve 
the congestion caused by the crisis, but such redundancy 
will also improve the probability that a working path still 
exists between two points where disaster has eliminated 
primary communication paths. 

As will be seen in the claim problem examined in this 
chapter, the existence of PSN path redundancy will be manda- 
tory to allow for allocation flexibility. The FAMIS DSS 
adjudication algorithms developed to solve the claim problem 
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must therefore be able to take advantage of PSN path redun- 
dancy as discussed above. 

B. THE CLAIM RESOLUTION PROBLEM 

For illustrative purposes, one of the questions 

discussed in Chapter 4 will be used as our example problem, 
namely. How can the number of users on the system be 

maximized? 

Resolution of this question will involve several steps: 

1. Determination of network status; what characterizes 
existing paths. 

2. Determination of user status; what recovery agents 
exist and where are they on the NETS. 

3. Determination of optimum allocation; how to connect 
the greatest number of recovery agents over the NETS 
simultaneously. 

These steps are discussed at length below. 

Certain characteristics of the NETS can be discerned by 
determination of network status as discussed in Chapter IV. 
For allocation purposes in our example problem, the charac- 
teristics of connectivity and capacity of the paths will be 
the relevant parameters of the NETS. 

J. LaPatra and C. Pierson have developed a Coefficient 
of Connectivity (CC), which defines mathematically all 
possible paths between two nodes (recovery agents) within 
the PSN [ Ref. 6] . Since the CC can be defined for every 
possible path within the PSN, it can also be defined for any 
remaining paths in NETS, since such remaining paths will be 
a subset of the original PSN. 

Given this ability to express every NETS path mathemati- 
cally, the FAMIS DSS could determine the capacity of these 
paths. Such determination would involve retrieving the 

capacity information for these paths from the DSS database 
and applying an update from the FAMIS manager to that infor- 
mation. Using a comparison program, the FAMIS DSS could 
then determine the lowest channel capacity link within this 
subset of system paths, since the capacity of any path can 
never exceed the capacity of its weakest link. 
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It should be emphasized that all paths in the PSN can be 
expressed individually in terms of the CC mentioned above. 
All PSN paths could therefore be defined in the FAMIS commu- 
nication resource database by their CCs, rather than by 
numbered node connections or geographic positions. Such 
definition by CC would make it easier for the FAMIS DSS to 
express the NETS status mathematically in optimization 
models. 

The determination of user status was discussed in 
Chapter IV. The user characteristics of interest in our 
example problem would be communication line capacity 
requirements and time requirements, since these requirements 
will determine which lines will meet the needs of certain 
recovery agents and the duration of their calls will deter- 
mine how many users can be queued for calls. 

The FAMIS DSS would retrieve these user characteristics 
from the recovery agent database. Note that user priority 
is not mentioned as a characteristic in our example. This 
omission is due to the emphasis on number of users, instead 
of priority use. 

The FAMIS DSS could then employ an optimization model to 
maximize recovery agent use of the NETS, subject to the 
constraints of existing system connectivity, lowest path 
capacity, user capacity requirements and user time require- 
ments. This optimization model could easily be adjusted to 
answer the other allocation questions listed in Chapter IV 
by altering the constraints. 

The example problem discussed in this chapter is only 
one of several questions addressed in Chapter IV, which does 
not address all possible ad hoc questions the FAMIS manager 
might have to answer to resolve all possible contingencies 
of communication resource allocation. The characteristics 
of the NETS and the recovery agents can be combined in many 
ways and each combination might require a different 
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allocation configuration. The example discussed in this 
chapter, however, is typical of the type of optimization 
problem which the FAMIS manager and his DSS will be required 
to resolve. 
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VII. THE FAMIS DSS 



This chapter will describe the required attributes of a 
decision support system for use with FAMIS. The three parts 
of any DSS will be described briefly to define the inter- 
faces between the manager and the DSS. Required and desired 
technical literacy of the manager will be discussed and 
coupled with necessary DSS functions. Finally, the informa- 
tion presented in this thesis will be summarized to identify 
required and desired characteristics of the FAMIS DSS. 

A. COMPONENTS OF A DECISION SUPPORT SYSTEM 

Decision Support Systems have been described in many 
different terms and categories. All decision support 
systems, however, are composed of the same three basic 
systems: Language System (LS), Knowledge System (KS), and 
Problem-Processing System (PPS). These three generic DSS 
systems are described briefly. 

KS. A knowledge system in a DSS is the body of knowl- 
edge a decision support system uses to answer questions. 
Databases, files and other stores of information are common 
parts of a KS. Information contained in a KS must be 
arranged in a systematic, organized manner. The KS portion 
of the FAMIS DSS would include recovery manager information, 
resource information, any standard arithmetic rules inherent 
in computer calculations and any other information which the 
DSS would retrieve and use to answer a question. 

LS. A DSS language system serves as the interface 
between the manager and the DSS. The LS can be defined as 
the total of all linguistic facilities made available to the 
manager by a DSS. As will be discussed later in this 
chapter, this interface can be designed to be as complex or 
as simple as required to be understandable to the manager. 



48 



PPS. The problem-processing system of a DSS takes the 
problems conveyed by the LS and, retrieving data from the 
KS, solves equations, compares data and otherwise analyzes 
and interprets data to provide information requested by the 
manager. 

The terms language system, knowledge system and program- 
processing system represent logical entities rather than 
strict physical components and there can be blurring of the 
lines of responsibility between these three sections. 
Different decision support systems will allocate certain 
functions, such as standard arithmetic functions, to the PPS 
instead of the KS. The DBMS might also reside in the PPS 
instead of the KS. It is important to realize that these 
sections are defined broadly because each DSS will be 
arranged to suit its specific purpose. 

The KS, arranged logically, interfaces with the PPS 
through a Data Base Management System (DBMS). As discussed 
in Chapter IV, the DBMS is a software program and it can 
reside in either the KS or the PPS. The DBMS retrieves 
selected information in a specified format from the KS and 
delivers this information to either the PPS or the LS, 
depending on whether the data must be acted upon or simply 
passed to the manager. 

If the data must be analyzed, calculated on or somehow 
transformed, the DBMS sends the data to the PPS. For 
example, in the FAMIS DSS the DBMS would retrieve data 
showing historical resource locations along with disaster 
model results and place the information into the PPS. The 
PPS would then compare the two data stores to determine the 
percentage and location of remaining resources. This infor- 
mation would be sent to the manager via the LS and would 
also be sent to the KS for retention for future use. 

For simple data retrieval, such as when the FAMIS 
manager wishes to see a graphic display of the NETS, the 



49 



DBMS would take the location data from the KS and send it 
directly to the LS. The LS would produce the graphic soft- 
ware necessary to project the map onto the manager's screen. 

B. THE FAMIS MANAGER 

Of the three DSS systems described, the language system 
(LS), as the interface between the DSS and the manager, will 
reflect to the greatest degree the FAMIS manager's level of 
computer literacy. The manager must be able to request 
information from the DSS. He must also be able to under- 
stand the answers the DSS produces. If the manager has 
little computer experience, then the LS must allow the 
manager to ask his questions in simple terms, perhaps as 
simple as colloquial English phrases, and must present the 
requested information in equally understandable terms, 
perhaps as simple as annotated map displays for depiction of 
NETS. 

An example of a data-retrieval type of DSS which allows 
the user to ask questions in colloquial English is the 
Language Access to Distributed Data with Error Recovery 
(LADDER) system used on the ARPANET system. LADDER is 
written in a complex computer language called INTERLISP. 
The designers of the LADDER program assumed the user would 
have no computer experience and they designed the program to 
accept questions and present answers in colloquial English. 
LADDER will accept questions that are not couched in 
complete sentences and will even try to figure out the 
possible meaning of misspelled words. This feature allows 
users who are not comfortable "talking" with a computer to 
convey their wishes to the system and receive usable infor- 
mation back. 

The LADDER system is somewhat slow, however, because the 
LS interface is so complex. The LS of any DSS must convert 
the user's requests into high-level computer code the PPS 
can accept to perform its tasks. If the user' s requests are 
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couched in varied English phrases, the LS must have within 
itself the necessary software to convert the English phrases 
to syntactically correct code. An additional problem with 
LADDER is that its LS will attempt to discern meaning from 
whatever phrases it receives and it sometimes misinterprets 
the user's meaning. 

These two problems, slow speed and possible inaccuracy, 
are intolerable in an emergency DSS. An LS which will 
accept input as unspecific as LADDER'S does is therefore 
unsuitable for the FAMIS DSS. It follows that the FAMIS 
manager must be at least somewhat familiar with computer use 
and methods of inputting and retrieving information. 

From the LADDER example described above, it can be 
inferred that the more computer knowledge the FAMIS manager 
has, the less complex the LS has to be and the faster the 
system will operate. It is not practical to assume, 
however, that the FAMIS manager should be able to couch his 
questions in high-level or pseudo code for several reasons. 

First, the FAMIS manager will most probably be a high- 
level government official. This presumption is based on the 
fact that the FAMIS manager will be given full authority to 
allocate communication assets nationwide during an emer- 
gency. As such an official, the FAMIS manager can be 
assumed to have a sound managerial background but, because 
computer literacy is only now becoming a requisite mana- 
gerial skill, it cannot be assumed that he will have worked 
with computers extensively before. 

Second, during an emergency the FAMIS manager may not 
have time to convert his questions from English into pseudo 
code or high-level code before entering them into the DSS. 

Third, since the LS interfaces with the PPS, it can act 
as a buffer to ensure the PPS receives information requests 
in the correct format. A simple LS allows the manager to 
interface more directly with the PPS and may result in inac- 
curate information being produced by the PPS. 
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It follows from this discussion that the FAMIS manager 
must possess at least some computer experience, but that he 
cannot be expected to know computer languages. The LS must 
require some structure of format in the requests it receives 
from the manager, but must still be sufficiently "user- 
friendly" to be understood by the manager. 

A menu-driven LS is a possible compromise. Menus in a 
computer program can be described as lists of choices which 
are presented to the user. The current FAMIS prototype 
computer program uses a menu to present the types of infor- 
mation available to the manager. This list was presented in 
Chapter II. The benefit of an LS which uses menus is that 
it is readily understandable by almost any user. The disad- 
vantage of a menu- driven LS is that the choices of informa- 
tion the manager can receive are limited to the choices 
presented by the menu. Such limitation of choices would be 
unacceptable where the FAMIS manager wanted to ask ad hoc 
types of questions, but could be used to initiate broader 
requests such as calling up a graphic map of the NETS or a 
list of all recovery managers. 

Whatever language system is selected for FAMIS, it must 
satisfy the criteria that it be understandable to a manager 
with the projected computer experience level of the FAMIS 
manager. Since the FAMIS manager will most probably be a 
high-level government official and therefore hard to find or 
replace, it will be much more efficacious to tailor the LS 
to the manager than to require the manager to become a 
computer expert. 

C. CONCLUSION 

This thesis has strived to identify the requirements of 
a decision support system to be used to help adjudicate 
allocation of scarce communication resources in concert with 
the Fly-Away Management Information System. 
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As with any emergency DSS, the FAMIS DSS must support 
the three criteria mandatory for emergency decisions: accu- 
racy, speed and interpretation of large amounts of uncorre- 
lated data. This thesis maintains these criteria can be 
best supported by a computer-driven DSS, housed in a micro- 
computer. Three examples of such emergency, computer-driven 
support aids were given. Although only one of the examples 
involved allocation of scarce resources (ambulances), the 
nature of the decisions faced by managers in all three exam- 
ples supports the necessity of a DSS which can support the 
three criteria mentioned above. 

The FAMIS DSS, like a human staff, must be able to 
provide the FAMIS manager with information upon request and 
must, at the same time, screen the information to ensure the 
manager does not have to deal with data unnecessary to reach 
his decision. Various software programs exist to perform 
these two categories of functions and most of those will 
work easily in a microcomputer. 

The questions associated with the allocation decisions 
the FAMIS manager must address are at the core of the issues 
of DSS design and the way in which the FAMIS DSS fits in 
with the rest of FAMIS. These questions can be grouped into 
the four main categories described in Chapter IV. It will 
be the FAMIS manager's ability to address these questions, 
using the DSS, which will make the DSS such a vital part of 
the Fly-Away Management Information System. 

The type of database and Data Base Management System 
(DBMS) to access the data will be important considerations 
for the FAMIS DSS. A relational database is recommended 
because it offers the data flexibility necessary to enable 
the FAMIS manager to ask ad hoc questions of the DSS. 
Regular updates of the data will be vital. Without current 
information, the DSS and therefore the decisions of the 
FAMIS manager will be inaccurate. 
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An example of a possible adjudication algorithm for 
allocation of scarce resources was discussed in Chapter VI. 
Many other algorithms will be needed to provide the analysis 
necessary to resolve all allocation questions. 

Possibly the most important part of the FAMIS 
manager/DSS system will be the computer literacy of the 
FAMIS manager. The DSS language system interface must be 
tuned to the manager's computer sophistication, since the 
DSS will be useless if the manager cannot input information 
or understand the DSS output. 

Figure 7. 1 depicts the flow of information into and out 
of the FAMIS DSS 

as discussed in this thesis. From Figure 7. 1, it can be 
seen that the DSS will need information from the recovery 
agents and communication resource databases, the FAMIS 
damage model program, and the FAMIS manager himself, along 
with the real-time resource claims of recovery agents to 
determine resource allocation recommendations. These recom- 
mendations must be sent to the FAMIS manager, not directly 
to the NETS, because the FAMIS manager must be the final 
arbeiter of allocation demands. 
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Figure 7. 1 Interaction of the FAMIS DSS. 
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